Session Initiation Protocol (SIP) is a signaling protocol for creating, modifying, and terminating multimedia sessions, including Internet telephone calls, with one or more SIP-endpoints. Details about the SIP signaling protocol is set forth in Internet Engineering Task Force Request for Comment 2543 entitled “SIP: Session Initiation Protocol,” March 1999 (hereinafter referred to as RFC 2543), which is incorporated herein by reference. SIP provides an alternative to PBX- or H.323-signaled telephony.
Although SIP end-points can directly place calls to one another, SIP servers, including proxy and redirect servers, are typically engaged during the call set-up process to route calls. Such call routing includes ascertaining called end-points in response to call establishment messages, referred to as INVITE messages, originated by calling end-points. The INVITE messages are either proxied to ascertained called end-points or the addresses of ascertained called end-points are returned to the calling end-points for allowing the calling end-points to directly place calls to the called end-points.
FIG. 1A is a functional block diagram for establishing a SIP call via a typical proxy SIP server 10. In step 30, the proxy server 10 receives an invitation from a calling end-point 15 in the form of an INVITE request. The INVITE request includes routing information in the “From:”, “To:”, “Contact:” and other standardized fields within the INVITE message header. The “To:” field of the message header includes a generic SIP URL associated with a called end-point 20.
The proxy server 10 accepts the INVITE request and in step 32, preferably engages a location server 25 for routing the call based on the routing information in the SIP message header. In this regard, the location server 25 retrieves the SIP URL associated with the called end-point to resolve the URL to a more precise address. For example, a call directed to a generic SIP URL such as, for example, “sales@acme.com” may be resolved to a particular person, such as, for example, “bob@ny.acme.com.” The retrieved address information is transmitted to the proxy server 10 in step 34.
In step 36, the proxy server 10 issues a second INVITE request to the more precise address. The called end-point 20 receives the second INVITE request and alerts the user of the request by, for example, causing the user's telephone to ring. If the call is answered, the called end-point 20, in step 38, returns a success indication to the proxy server 10 via an OK response. The proxy server 10 forwards the OK response in step 40 to the calling end-point 15. The receipt of the success result is confirmed by the calling end-point 15 by transmitting an ACK request to the proxy server 10 in step 42, which then forwards it to the called end-point 20 in step 44.
FIG. 1B is a functional block diagram of an alternative method for establishing a SIP call using a typical redirect SIP server 47. In step 31, the redirect server 47 accepts the INVITE request and, as the proxy server 10 of FIG. 1A, contacts the location server 25 in step 33 for routing the call based on the routing information in the INVITE message header. The redirect server 47, instead of directly contacting the newly found address received in step 35, returns the address to the calling end-point 15 in step 37. The calling end-point 15 confirms receipt of the address via an ACK request in step 39.
The calling end-point 15 issues a new INVITE request to the address returned by the redirect server 30 in step 41. If the call succeeds, the called end-point 20 transmits an OK response in step 43, and the calling end-point 15, in step 45, completes the handshake with an ACK request.
One limitation in current SIP call routing is the limited information on the caller's intent that may be deduced at the time the call is initiated from standard routing fields within the INVITE message headers. In order to gather additional call intent information for routing a call, conventional approaches often make use of interactive voice response (IVR) systems, whereby the caller is prompted for and provides additional information on the caller's intent through selection of dual tone multi-frequency (DTMF) digits on the telephone keypad. For example, a person making a call to a general address may be asked to enter account information through use of DTMF telephone keypad digit entry, and select a particular department, such as customer service, sales, or marketing department. Only after this information is entered can the call be appropriately routed to a suitable call center operator. Use of IVR systems to ascertain additional caller intent information is very cumbersome and inconvenient for the caller, and requires additional message exchanges and database lookups, which translate into slow call setup times and frustration for the caller.
Conventional telephony systems may employ caller ID data that is automatically transmitted with an incoming call in lieu of DTMF key entries to route the call. However the data transmitted is limited to caller ID data, and does not include additional caller intent information that may be desirable to more intelligently route a call.
Newer systems may employ voice recognition techniques in response to IVR prompts to deduce the caller's intent. However, such voice recognition systems are also cumbersome and inconvenient for the caller, subject to error, and also yield slow call setup times.
Accordingly, there is a need for a more efficient system and method for ascertaining caller intent information for intelligent and efficient routing of incoming calls.